看著今天挑戰第 29 天，不小心以為是今天燃燒第 29 天，我想我一定是累了...話說行百里半九十，就快到終點了！！吶喊前進！！就在我差點斷炊的時候，讓我想到最近處理的一個事件，我覺得跟 DevOps 也滿有關的。

事情是這樣的，因為機器資源管理的需求，所以我們收到系統單位的通知，希望我們有兩台網頁的機器可以暫時關機，讓他們做搬移後再重啟，時間大約是十分鐘，再加上我們的檢查時間，我們估計大約會需要 20 分鐘，這個網頁服務是當客戶反應線路有問題時，讓維運人員可以直接透過網頁介面調整線路的服務。

於是我們跟系統單位約定好時間後，告知維運團隊在某個時間區段，請暫停使用後臺服務，當然，我們有挑選客訴相對少的時間，以往維運團隊會說沒問題，如果暫停服務的當下有客訴，他們會直接請我們協助調整，但這次值班的人給了不一樣的回應，是直接回應「那這樣有客訴不就不能處理？有其他的替代使用方式嗎？」，然後這次配合的開發人員也給了另一個回應「你可以先改用某某網址來連？以達到你要的使用目的」。

我不解地詢問回覆的開發人員：「為什麼某某網址也可以使用相同服務？」
開發人員：「那是 API 機器，只是也有放上網頁服務的程式，可以暫時讓對方先使用」

跟以往小小的不一樣，讓我想到是不是我們在架設服務時，除了考慮負載平衡以外，也要考慮當機器需要維修/搬移時，執行方式是否可以讓使用者無感，要準備好替代方案，又或者是在設計架構時，就跟相關單位密切討論，把資源分散在不同地方，而不是單純的依賴系統團隊，隨意配置。

這樣一說，我又想到曾經發生過的案例是當機器發生問題時，開發工程師請維運單位把機器拉下線，開發工程師以為負載平衡下還有其他機器可以提供服務，但實際上其他台機器可能因為其他因素在前幾天已經被拉下線，而維運工程師也沒有仔細考量，接到需求就執行，於是就造成更嚴重的服務異常。

想這類的問題，如果可以把系統的資訊整理好呈現，讓系統單位、維運單位甚至是開發單位都可以對整體架構配置一覽無遺，共享資訊，我想應該可以有更理想的配置，處理問題也可以更加順暢。